-
Notifications
You must be signed in to change notification settings - Fork 417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Analysis API to 2.1.20-dev-4370 #3802
Update Analysis API to 2.1.20-dev-4370 #3802
Conversation
8decdca
to
3a3ffbd
Compare
83e35b1
to
e0f78b4
Compare
…ev/update-analysis-api-to-2.1.0-dev-7103
86156e2
to
9e26139
Compare
.../src/main/kotlin/org/jetbrains/dokka/analysis/kotlin/symbols/plugin/SymbolsAnalysisPlugin.kt
Show resolved
Hide resolved
@vmishenev could you rebase on latest master? I see test failure on CI which is fixed there |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main question at my side is, how it will affect end-users?
I mean, okay, we "patched" (via scary flag SoftRefLRUPolicyMSPerMB
) our test, but what will be on user-projects without it?
In any case, it would be nice to update PR description with what and why we are doing here
Also, I think we should check, that it will work fine with DGPv2, at least in IT before merging.
And also we should test combination DGPv2 + K2 with bigger external projects (kotlinx, ktor) before 2.0.0 release, so that we are sure that it works fine keeping in mind the difference in how Dokka is executed
* Note: Disposing of resources, including threads, allows unloading Dokka's class loader. | ||
*/ | ||
@InternalDokkaApi | ||
public fun disposeGlobalStandaloneApplicationServices() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we add this function inside analysis-java-psi
module and not call directly inside K2 analysis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only from analysis-java-psi
, you can call the methods of the IJ Platform. The K2 module has the truncated version of IJ from the compiler dependencies.
On the other hand, the calling of disposeGlobalStandaloneApplicationServices
might affect the PSI analysis somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, Marco will merge the endpoint into AA so we will be able to call it from K2. I left TODO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably it will be nice to also create an issue on our side, to keep track of it
dokka-subprojects/plugin-base/src/test/kotlin/model/ClassesTest.kt
Outdated
Show resolved
Hide resolved
jvmArgs = listOf("-Xmx1G", "-XX:MaxMetaspaceSize=500m"), | ||
jvmArgs = listOf( | ||
"-Xmx1G", "-XX:MaxMetaspaceSize=500m", | ||
"-XX:SoftRefLRUPolicyMSPerMB=10" // to free up the metaspace on JVM 8, see https://youtrack.jetbrains.com/issue/KT-55831/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really like that we need to add this flag here, only in tests... But not sure, that there are a lot of users which will be affected by issue with JDK 8 (note: Gradle migrating to JDK 17 by default for execution)
Overall, as far as I understand, this means, that K2 analysis could cause OOM on user projects with JDK 8? I think it would be nice to mention this in release notes if so, WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, as far as I understand, this means, that K2 analysis could cause OOM on user projects with JDK 8?
Yes, but as you said it is unknown how many real user projects it affects.
This test is quite artificial with almost no code.
On real projects with the same number of modules, the behavior of JVM 8 might be different.
.../src/main/kotlin/org/jetbrains/dokka/analysis/kotlin/symbols/plugin/SymbolsAnalysisPlugin.kt
Show resolved
Hide resolved
.../src/main/kotlin/org/jetbrains/dokka/analysis/kotlin/symbols/plugin/SymbolsAnalysisPlugin.kt
Show resolved
Hide resolved
...ts/analysis-java-psi/src/main/kotlin/org/jetbrains/dokka/analysis/java/JavaAnalysisPlugin.kt
Show resolved
Hide resolved
I do not know) This test is quite artificial with almost no code.
Another "popular" solution is increasing memory. It does not work for the stress test since its goal is to check the consumption of memory. There are some observations:
Does it really block merging? Haven't we checked DGPv2+K2 in IT at all yet?
Sure |
…ev/update-analysis-api-to-2.1.0-dev-7103
Okay, let's merge at test it manually and add DGPv2 + K2 testing separately.
Yeah, let's see how it will go. |
* Note: Disposing of resources, including threads, allows unloading Dokka's class loader. | ||
*/ | ||
@InternalDokkaApi | ||
public fun disposeGlobalStandaloneApplicationServices() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably it will be nice to also create an issue on our side, to keep track of it
dokka-subprojects/core/src/main/kotlin/org/jetbrains/dokka/configuration.kt
Show resolved
Hide resolved
JIC I have tested K2 with DGPv2 on a project (50 submodules) from the stress test (where a special VM flag is used). It works well on JVM 8 without any additional options or flags. Update: I also tried with |
The goal of PR is to update Analysis API to the latest version -
2.1.20-dev-4370
.After some changes in AA, it is necessary to dispose of global resources (including threads of workers) at the end of the analysis to avoid memory leaks when rerunning the Dokka task (see https://youtrack.jetbrains.com/issue/KT-71862/Analysis-API-Standalone-Memory-leak-LowMemoryWatcherManager-does-not-release-resources ).
Also, Dokka encountered exhausted metaspace memory during one of the stress tests. On JVM 9 and later, the test passed successfully, but it failed on JVM 8, even with doubled or tripled memory. We resolved the issue using the flag
-XX:SoftRefLRUPolicyMSPerMB=10
(collect soft references more aggressively) from KT-55831 on JVM 8.